_{Comment @coderabbitai help to get the list of available commands and usage tips.}

🚀 Preview Deployment

🔗 Preview Links

Service	Status	Link
Database (Neon)	✅	View Branch
Electric (Fly.io)	✅	View App
API (Vercel)	✅	Open Preview
Web (Vercel)	✅	Open Preview
Marketing (Vercel)	✅	Open Preview
Admin (Vercel)	✅	Open Preview
Docs (Vercel)	✅	Open Preview

Preview updates automatically with new commits

Nice end-to-end implementation: API surface is tiny, desktop fails open on config fetch/parse issues, and the “Update required” UI is clear.

A few concrete things I’d tighten up before merging (mostly reliability / long-term maintainability):

1) Make the API response explicitly non-cacheable (remote config should actually be “remote”)
apps/api/src/app/api/public/desktop/version/route.ts currently returns a plain JSON response. Depending on how/where apps/api is deployed, it’s easy for this kind of GET endpoint to get cached somewhere (CDN/proxy/framework defaults), which would make changing DESKTOP_MINIMUM_SUPPORTED_VERSION take much longer than expected (or require redeploys).

Suggestion: set Cache-Control: no-store (and, if relevant in this Next setup, force dynamic behavior).

// apps/api/src/app/api/public/desktop/version/route.ts
export const dynamic = "force-dynamic";

export function GET() {
  return Response.json(
    { minimumSupportedVersion: env.DESKTOP_MINIMUM_SUPPORTED_VERSION ?? null },
    { headers: { "Cache-Control": "no-store" } },
  );
}

2) Semver parsing/comparison: either reuse a proven impl, or add guardrails/tests
apps/desktop/src/shared/utils/semver.ts is clean and readable, but semver edge cases are notoriously tricky.

Two specific nits if you keep the custom version:

• localeCompare (line 68) is locale-sensitive; for semver precedence you generally want a simple deterministic lexicographic compare (e.g. aId < bId ? -1 : 1) rather than locale collation.
• The regex accepts prerelease/build strings pretty loosely (e.g. empty prerelease identifiers). Might be fine given the controlled input, but it’s a footgun if the env var ever gets set incorrectly.

Given this is a “hard gate,” I’d strongly consider either:

• adding a small suite of unit tests for compareSemver / isSemverLt (cover prerelease ordering rules, v prefix, build metadata ignored), or
• using the semver package (noting you already have @types/semver in apps/desktop).

3) Version gate invalid-semver warning is a bit misleading
In apps/desktop/src/main/lib/version-gate.ts, isSemverLt() returning null could mean either currentVersion or minimumSupportedVersion is invalid, but the log says “Invalid semver in minimumSupportedVersion” (line 70). Consider logging both values (and/or tailoring configFetchError) to make future debugging less confusing.

4) Auto-update subscriptions still run even when “disabled” (minor perf + duplicate listeners)
In MainScreen, useUpdateListener({ enabled: !versionGateStatus?.isUpdateRequired }) prevents toasts, but the underlying trpc.autoUpdate.subscribe subscription is still active (useUpdateListener.tsx lines 18–62). When gated, you also subscribe again inside UpdateRequiredScreen (line 31), so you end up with two subscriptions.

Suggested refactor: split MainScreen into a small “gate” component (fetches versionGateStatus and chooses which screen to render) and a child component for the actual app that calls useUpdateListener(). That way the subscription only exists in the non-gated path, and UpdateRequiredScreen owns the only subscription in the gated path.

5) Small nits

• apps/desktop/src/lib/trpc/routers/version-gate/index.ts: the async wrappers around getVersionGateStatus() aren’t needed (it already returns a promise). Not a big deal, but simplifies a bit.

Overall this looks close; the main “I’d really like to see this” item is the non-cacheable config endpoint, since caching would undermine the core purpose of the feature.